home *** CD-ROM | disk | FTP | other *** search
- Hints for programmers: (updated 22-Oct-91)
- ==========================================
-
- !IMPORTANT NOTE FIRST!
- ----------------------
-
- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- Since V2.07 I supply the lmkfile I USE (before I supplied one, I just built
- for the distribution disk), because I don't want to hassle around with two
- different lmkfiles. I too often forget to adapt the second one after making
- changes to the first. The big differences between those two was: in the
- lmkfile I REALLY used, I use my own linker library (ex.lib) for certain
- small routines (Ellipse,Line...); in the lmkfile I SUPPLIED these routines
- were located in an extra file (extra.c). I did this to give owners of an
- Aztec-C-Compiler a chance to recompile the files. Meanwhile I use so many
- SAS/Lattice C specific things (e.g. __chip keywords), that I don't think
- any Aztec user will have much use of the source files. So to make life a
- bit easier for the SAS/Lattice owners (and for me too, of course), I now
- just supply the really used lmkfile AND the lib (ex.lib). I didn't have
- time to document it, yet, as soon as I have, I will distribute it on PD.
- All desperate Aztec users, who for some reason want to recompile the
- sources with their compiler can write in to me (i.e. send me a disk) and I
- will return the full source code (incl. the ex.lib source).
- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-
-
- Now the other interesting things:
- --------------------------------
-
- First, all source files have been compressed into an archive (Source.LZH)
- using Lharc V1.30 (AmigaLibDisk 404). I have included Lharc V1.30 on my
- distribution disk. However I don't know if all PD-distributors leave it
- there, so you may be have to get elsewhere. All other (older) versions of
- Lharc should also work, though I have not tested them.
-
- All source files have been compiled with the SAS/Lattice C 5.10a Compiler.
- See below for problems concerning the optimizer! All files use
- 32-bit-integer variables so I hope there is no problem in this aspect.
-
- Besides source-file-specific headerfiles (*.h) which are located in the
- source root directory (on the same level as the *.c files they belong to),
- I provide all the needed header files for the req.library, the arp.library
- and the iff-saver (ilbmw.c). Because I now (since V2.07) provide
- also the source code of 'ConvM3D', I now store all source files with their
- pathnames. This will lead to problems during the compile process,
- because it is very unlikely that you use the same directory
- structure as I do. This causes problems when you compile certain files (for
- example ilbmw.c), because the include files are supposed to be located in a
- subdirectory (in this case iff/). You may either change the #include lines
- in the problematic files or you may create a subdirectory INCLUDE below the
- source root directory and include the -i option in the lmkfile at the
- CFLAGS. If you do so I recommend to organize the files as follows:
-
- source/
- *.c source-files
- *.h other header files
- extra.c has to be moved from pdomain/ to the source root directory!!!
- lmkfile automatic compilation and linking if you use LMK, has to be
- moveded from pdomain/ to the source root directory!!!
- include/
- clib/
- req_protos.h
- libraries/
- reqbase.h
- arpbase.h
- iff/
- compiler.h
- gio.h
- iff.h
- ilbm.h
- packer.h
- proto/
- arp.h
- mtwx_defs.h
- req.h
- convm3d/
- convm3d.c main file for ConvM3D
- rev.c revision code for ConvM3D
- lmkfile automatic compilation and linking if you use LMK
-
- A lmkfile is provided, so Lattice users could simply type LMK and the
- compile process will run automatically (see below for the memory problem).
-
- **** PROBLEM:
- Unlike the old Aztec C Compiler (V3.6a), the SAS/Lattice C Compiler 5.10a
- needs a terrible amount of memory during the compilation process. I have
- great problems in compiling the main file (chemest.c) even though I've got
- 1 MByte RAM. I have to disconnect my external drive and switch off MachIII
- even though I place the quad file on my hard disk (-qdh0:). If anybody has
- a solution to this, please let me know. It seems to be a problem of the
- precompiler, because most of the memory has been eaten up before the real
- compilation process is started (I used SnoopDos to check this). What do the
- users with just 512 KByte do, Lattice ? It seems impossible to me that they
- can compile any program that #includes more than eight files.
- I will try to chop the chemest.c into several smaller files and #include
- exactly what is needed and won't use a (large) precompiled header file.
- Maybe this will do for a while, but this can't be the solution, Lattice. I
- hope there will be a solution with the next compiler release.
-
-
- I have some problems in writing a convenient message-receiving routine.
- Sometimes the GURU will visit you if you select a menu or close a window. I
- reduced the frequency of the Guru's appearance by using ARP's
- CloseWindowSafely() instead of Intuition's CloseWindow(), but it still
- happens sometimes. PLEASE: If anyone has a solution for this please let me
- know. I looked thru lots of computer magazines but I didn't find anything
- else than my Nachricht() (-> Message) routine.
-
- I use my own (well actually it comes from QuickReq.c from AmigaLibDisk457)
- _main() routine to get rid of that f***ing console window that is opened by
- all files compiled with the Lattice compiler (take that away Lattice, it
- must be up to the programmer to include this!). The console window that is
- now opened is my own (see OpenRevWin in extra.c) and I need it to display
- certain messages.
-
- By now I use the following routines outside of AmigaDOS, Intuition etc.:
-
- ArpAlloc arp.library
- CloseWindowSafely arp.library
- FileRequester req.library
- SimpleRequest req.library
- TwoGadgetRequest req.library
- SetLocation req.library
- ReadLocation req.library
- SetSize req.library
-
- I do not use the req.library's palette requester because it does not have
- all the things a good palette requester has to have. Instead I use Jonathan
- Potter's paletterequest(). Thanx Jonathan, it's old, but it's still the
- best!
-
-
- Do not change rev.c, as it has a special format that is needed by other
- files.
-
- All source files come with German comments and (partly) German names for
- routines and variables. If you would like to know what they mean, well, try
- learning German, it's a fascinating language.
-
- The newer files are ANSI-C compatible and they are compiled with the -ca
- option of the compiler. The current version is a mixture of ANSI and
- non-ANSI files, I intend to make ALL files ANSI compatible in the future.
-
- I intended to provide a makefile for Aztec C users and to embedd Lattice
- specific things in #ifdefs but I didn't have the time yet. If somebody does
- this, I would like to get a copy of this. If nobody does I may do it on my
- own somewhere in time... Let's wait'n'see!
-
-
- Some words about optimization:
- ------------------------------
-
- Due to my lack of leisure time, I can't optimize the program as much as I
- want to, so I handed this over to the global optimzer GO (Option -O) of the
- SAS/Lattice C packet. Unfortunately, GO does seem to have some bugs. In the
- released version V2.06 the input of data is *NOT* possible, the program
- crashes while or before modifying the prop-gadget. While debugging (and for
- that removing the -O option), the error didn't occur. Same as with the
- palette requester. So I changed the lmkfile so that neither palettereq.c
- nor eingabe.c will be optimized. If you use your own lmkfile be aware of
- that. DON'T OPTIMIZE palettereq.c AND eingabe.c!!
-
-
- Have fun!
-
- Joerg
-
-
- P.S. None of the files may be touched, changed, deleted or distributed on
- own series of Stefan Ossowski PD-Versand, Rainer Wolf PD-Versand
- (OASE) and Markt & Technik Verlag AG,
-
- Greetinx to Bernstein Softworks (Risk, Dragon Cave) for their RIGHT
- attitude concerning some kind of PD distributors.
-
-